Compiling executable code into a less-trusted address space

ABSTRACT

Unsafe application programs that implement managed code can be executed in a secure fashion. In particular, an operating system can be configured to execute an application program in user mode, but handle managed code compilation through a type-safe JIT compiler operating in kernel mode. The operating system can also designate a single memory location to be accessed through multiple address spaces with different permission sets. An application program operating in user mode can be executed in the read/execute address space, while the JIT compiler operates in a read/write address space. When encountering one or more pointers to intermediate language code, the application runtime can send one or more compilation requests to a kernel mode security component, which validates the requests. If validated, the JIT compiler will compile the requested intermediate language code, and the application program can access the compiled code from a shared memory heap.

CROSS-REFERENCE TO RELATED APPLICATIONS

N/A

BACKGROUND

1. Background and Relevant Art

As computerized systems have increased in popularity, so have thevarious application programs used on the computerized systems. Inparticular, there are now a wide range of applications programsconfigured for any number of purposes, whether to function as complexoperating systems, databases, and so forth, or as a simple calculator.In many cases, software developers will write new application programswith a particular operating system in mind, using any number ofappropriate languages. Once the software is complete, the developer willcompile the application into machine-executable code, which can then beinstalled on a computer system with the appropriate operating system.

One will appreciate, therefore, that there are a number ofconsiderations that often must considered by developers of operatingsystems as well as of the individual application programs. Many of theseinterests may even be competing. For example, many application programdevelopers may have interests related to quick and fast operation, whilemany operating system developers may have interests related to securityand stability. In some cases, the security and stability requirementscan cause some application programs to have slower execution and/orlower-performance.

For example, the operating system may be configured to have applicationprograms run in a less-trusted “user” level, but have other systemcomponents run in a trusted “kernel” level. As a result, an applicationprogram running in a user level might only be able to perform certaintypes of functions by requesting the given function through anintermediary, trusted component. The intermediate component can thenvalidate the request and then pass the request for the function to akernel level component, which can then execute the request.

Other ways of managing security are to limit the various applicationsand components to specific readable, writable, and/or executablepermission spaces. For example, an operating system might allow certainapplication programs to run only in a read/execute address space. Thismight allow the application programs to execute any existinginstructions, but would prohibit the application from performing anywrite operations. By contrast, the operating system might allow othersensitive system components to operate only in a read/write addressspace. This might allow the sensitive components to make new writes, butwould prohibit those writes from being executed.

In still other cases, an operating system might allow only certain typesof application programs conforming to certain code standards to run in aspace that is readable, writable, and executable. For example, theoperating system might only allow “type-safe” applications to run in aread/write/execute address space. One example of a type-safety rulemight be to require an integer value to be added only to other integervalues, rather than to floating point values. A type-safe compiler couldthen be used to compile only that executable program code that istype-safe, and thus trusted by the operating system.

Unfortunately, some recent trends in application program developingcomplicates various aspects of the above-mentioned security managementapproaches. For example, a wide range of application developers are nowcreating video game application programs using “managed code.” Ingeneral, managed code includes executable program code, as well asintermediate language code that can be compiled on an as-needed basis.For example, a developer of an application program might include one ormore references (in the compiled, executable code) to intermediate code.Thus, when the executable code comes to a point where it needs to use afunction that is available only in intermediate language code, a JIT(just-in-time) compiler is used to compile certain intermediate languagecode into executable instructions.

One can appreciate, therefore, that operating systems will sometimeslimit the use of managed code to type-safe applications. In particular,since the JIT compiler will need to write, and since the applicationwill need to execute, and further since the application program willneed to access the compiled code written by the JIT compiler, the JITcompiler and the executing application program will typically operate inthe same address space, which is readable, writable, and executable.Thus, if the intermediate language code were not type-safe (orconforming to some other program code restrictions), a malicious partycould trick the JIT compiler into generating harmful instructions thatare executed.

Unfortunately, program code restrictions such as type-safety are oftenbelieved to conflict with speed and performance considerations. This canbe particularly problematic for video game applications, where speed andperformance considerations are placed at a premium. In some cases,therefore, the developers of video game applications may find it betteror more efficient to ignore specific code specifications, such astype-safety.

BRIEF SUMMARY

Implementations of the present invention provide systems, methods, andcomputer program products configured to allow for the use of managedcode in an operating system, where the managed code may not necessarilyconform to any particular code standard. In one implementation, forexample, an operating system provides access to a memory location in twodifferent address spaces, and sets the permissions in the addressspaces, such that the memory location is accessible with differentpermissions from the two different address spaces. In oneimplementation, a JIT compiler operating in one address space passescompiled code into a shared memory heap. Executable program code, inturn, accesses the compiled code from the memory heap, and executes itin the other memory address space.

For example, a method of executing managed code so that untrustedprogram code can be compiled and executed in a manner that does notthreaten or otherwise compromise system security can involve executingan application program in a first address space of a memory location.The method can also involve receiving one or more requests from theapplication program to compile one or more sets of intermediate languageinstructions. In addition, the method can involve compiling the one ormore sets of intermediate language instructions into newly compiled codeusing a JIT compiler running in a second address space of the memorylocation. Furthermore, the method can involve passing the newly compiledcode to a shared memory heap. The application program can then retrievethe newly compiled code from the shared memory heap into the firstaddress space.

Similarly, another method of generating computer executable program codein a manner that uses JIT compilation while avoiding security violationscan involve receiving application program code that includes executablecode and code to be compiled. The method can also involve executing theexecutable code in a lower-privilege mode and in a first address space.In addition, the method can involve identifying one or more pointers inthe executable code for at least some code to be compiled. Furthermore,the method can involve switching to a higher-privilege mode. Stillfurther, the method can involve compiling the at least some code in adifferent address space using a compiler operating in thehigher-privilege mode.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be obvious from thedescription, or may be learned by the practice of the invention. Thefeatures and advantages of the invention may be realized and obtained bymeans of the instruments and combinations particularly pointed out inthe appended claims. These and other features of the present inventionwill become more fully apparent from the following description andappended claims, or may be learned by the practice of the invention asset forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1A illustrates an overview schematic diagram of an implementationin accordance with the present invention in which an application programrunning in a less trusted security mode invokes managed code, which iscompiled by a JIT compiler in a trusted security mode;

FIG. 1B illustrates a schematic diagram in which a memory locationmanaged by the operating system is accessible by components in twodifferent address spaces, which have different permissions for accessingthe memory location;

FIG. 2 illustrates a flowchart of a sequence of acts in accordance withan implementation of the present invention in which a JIT compilerreceives and handles one or more requests for intermediate languageinstructions; and

FIG. 3 illustrates a flowchart of an overview sequence of acts in whichan operating system receives an application program that includes one ormore references to managed code, and executes the application program inaccordance with one or more security mechanisms.

DETAILED DESCRIPTION

Implementations of the present invention extend to systems, methods, andcomputer program products configured to allow for the use of managedcode in an operating system, where the managed code may not necessarilyconform to any particular code standard. In one implementation, forexample, an operating system provides access to a memory location in twodifferent address spaces, and sets the permissions in the addressspaces, such that the memory location is accessible with differentpermissions from the two different address spaces. In oneimplementation, a JIT compiler operating in one address space passescompiled code into a shared memory heap. Executable program code, inturn, accesses the compiled code from the memory heap, and executes itin the other memory address space.

As will be understood more fully herein, implementations of the presentinvention can provide a secure system without necessarily needing toverify that the generated code does not violate the security constraintsof the system. This can be done at least partly by “sandboxing” thecompiled code, as well as any other code that is being executed. Inparticular, implementations of the present invention can define a“sandbox, ” which is essentially a predefined set of boundaries in whichany type of code can be executed. Specifically, the sandbox boundariesdescribed herein will result in malicious request(s) made by theexecuting code being either denied by the operating system (as comingfrom a user mode component), or limited to actions or functions onlywithin the predefined permissions (e.g., denying a write to aread/execute address space).

As a result, code that is compiled by a JIT compiler (e.g., 105), oreven the application program (e.g., 110) ultimately invoking the JITcompiler, can be executed within the sandbox without necessarily being“type-safe,” or conforming to some other security consideration. Onewill appreciate that this can free a given developer to writeapplication program code in a manner that is potentially lessconstrained, and potentially faster and performance driven thanpreviously possible.

In addition to ensuring that code is executed properly, implementationsof the present invention also provide mechanisms that ensure that theJIT compiler, itself, cannot be “hijacked,” such as when receiving andcompiling intermediate language code. In particular, implementations ofthe present invention include a JIT compiler that is configured fortype-safe execution, rather than necessarily checking incoming code fortype-safety or compiling only type-safe code. As such, the JIT compilerin accordance with implementations of the present invention can beprotected against requests that would cause the JIT compiler itself toviolate safety definitions (e.g., type-safe definitions).

In one implementation, for example, the JIT compiler can be configuredwith type-safety definitions that restrict the JIT compiler fromreaching outside of its own data structures, or the data structures thatare defined as part of the system 100 runtime. For example, the JITcompiler can be configured to perform a series of checks to ensure thatonly valid casts are performed whenever performing casts from one typeto another. Similarly, the JIT compiler can be configured so that,whenever asked to read out of arrays, the JIT compiler performs one ormore boundary checks to ensure that the JIT compiler is within thebounds of the array. With respect to use within the C programminglanguage, for example, the JIT compiler can also be configured to ensurethat whenever using a “union,” the JIT compiler reads or writes to theproper part of the union. Furthermore, the JIT compiler can beconfigured to ensure the JIT compiler never overflows or underflowswhile reading or writing the type-stack (the type-stack within the JITcompiler).

In general, the JIT compiler's type-stack is an internal data structurethat is generally important to maintain correctness, etc. For example,intermediate language code is typically a stack-based system in whichthe JIT compiler operates on objects in a stack in order, and placesresults back into the stack in order. The JIT compiler in accordancewith implementations of the present invention is thus configured tosimulate a stack to ensure that the JIT compiler is operating asexpected. For example, the JIT compiler can perform stack simulationwhile compiling intermediate language code. If the simulated stackdeviates significantly from what the JIT compiler is being fed, the JITcompiler can quit compilation or generate an error. This helps the JITcompiler ensure that it is operating within prescribed boundaries, andthus protected from violating one or more security rules.

FIG. 1A illustrates an overview schematic diagram of a computerizedsystem 100 (e.g., a video game operating system) in which an applicationprogram (i.e., 110) is being executed. In one implementation,application program 110 is a video game application, though one willappreciate that application program 110 can be any type of executableprogram code. In any event, FIG. 1A also shows that application program110 comprises one or more sets of executable instructions, such ascompiled code 135, which includes a pointer 140 to intermediate language(“IL”) code 120. Similarly, FIG. 1A shows that application program 110comprises compiled code 145, which includes pointer 150 to intermediatelanguage code 125. Intermediate language code 125, in turn, comprisesseveral different components or modules, such as code 120, 125 and 130,which need further compilation before they can be executed.

There are any number of different ways that application program 10 willor can be executed in computer system 100. For example, a user mightload a storage device onto another device on which the system 100 isinstalled. The storage device may include binary executable code forapplication program 110, as well as managed code in the form ofintermediate language code 115. Both the executable code andintermediate language code of application program 110 could then beloaded into computerized system 100. In other cases, a user, such as adeveloper, may upload the application program 110, includingintermediate language code 115 through a network connection. In such acase, the user might be executing application program 110 for testingnewly developed application programs (e.g., 110).

In any event, FIG. 1A also illustrates that application program 110 isbeing executed in a lower-privilege mode (e.g., “user” mode), while JITcompiler 105 is operating in a higher-privilege mode (e.g., “kernel”mode). For example, FIG. 1A shows that application program 110 isoperating in user mode 113 with user privileges, while JIT compiler 105is operating in kernel mode 103 with corresponding kernel privileges. Inaddition, FIG. 1A shows that intermediate language code 115 is accessedby one or more components with kernel 103 level privileges. Conversely,and as will be understood more fully herein, executable code will onlybe executed by components operating with user 113 levels of privileges.

Accordingly, as the runtime for application program 110 executes each ofthe compiled instructions 135, 145 in user 113 mode, the runtime willcome across any of one or more pointers to intermediate language code.For example, during execution, the runtime for application program 110comes across pointer 140 to intermediate language code 120. Sincepointer 140 references code that can only be accessed in kernel 103mode, the runtime will break out of user mode and system 100 will switchto kernel 103 mode.

The request 143 will then be handled by security component 155, whichoperates in kernel 103 mode. In general, security component 155 cancomprise any number or type of components or modules configured toreceive a user mode 113 component request (e.g., 143), and then validatewhether the request is appropriate. This is done since user mode 113 isuntrusted, and since application program 110 may or may not represent(or otherwise include) dangerous or malicious code.

Thus, to ensure that requests from user mode 113 execution will notdamage system 100, security component 155 can perform any number or typeof validation functions. For example, security component 155 can reviewmessage 143 for any number of handles, tokens, or the like. Furthermore,security component 155 can review request 143 for applicationinstructions that could be used to compromise system 100, such asspecific memory address requests, or requests that could result in abuffer overrun, etc. Upon validating request 143, security component 155can initiate JIT compiler 105 in kernel mode.

Once operating in kernel mode, JIT compiler can then be fed therequested code (i.e., 120) and begin compilation. For example, FIG. 1Ashows that security component 155 executes one or more requests 147 thatcause JIT compiler 105 to receive and compile intermediate language code120. After compiling code 120 into executable binary instructions (i.e.,compiled code 123), FIG. 1A also shows that JIT compiler 105 can thenpass code 123 into memory heap 160.

As will be understood more fully with respect to FIG. 1B, memory heap160 straddles the boundary between user mode 113 and kernel mode 103operations. In effect, memory heap 160 acts as across-permission/cross-boundary store that is accessible by componentsoperating in kernel mode 103 and/or in user mode 113. Once compilationis completed, system 100 can switch back to user mode and continueexecution of the application program 110. In particular, application110—operating in user mode—can pull the compiled code 123 as soon as itis available, and begin executing it in user mode 113. One willappreciate, therefore, that memory heap 160 can be used to help maintainthe security boundaries between the two security layers by allowing JITcompiler 105 and user 113 to function independently, in differentprivilege modes, without direct communication.

FIG. 1B illustrates additional details on how the security boundarybetween the JIT compiler 105 and application program 110 can beaccomplished or otherwise maintained. In particular, FIG. 1B illustratesan implementation in which JIT compiler 105 and application program 110operate with respect to a particular same memory location, albeit withdifferent permission sets. In particular, FIG. 1B illustrates animplementation in which the same memory location can be accessed bycomponents in one address space with one set of permissions in oneaddress space, and accessed by different components in another addressspace with a different set of permissions. For example, FIG. 1B showsthat memory location 160 is available in an address space 170 withread/write permissions, and an address space 165 with read/executepermission.

In general, one or more kernel layer 103 components of operating system100 will maintain a memory page table 180 for any given address locationand corresponding address spaces. For example, FIG. 1B shows that memorypage table 180 is maintained in kernel 103 layer (i.e., one or morekernel mode components) of system 100. One reason this is maintained bya kernel 103 mode component is to ensure that an untrusted applicationprogram (i.e., operating in user mode) cannot access or otherwiseimproperly manipulate the page table.

In any event, FIG. 1B shows that page table 180 correlates memorylocations 160 and 165 with address spaces 170, 175, 190, and 195. Forexample, memory location 160 is the shared memory heap, while memorylocation 165 is a location in which application program 110 is loadedfor execution. In addition, page table 180 maps the access permissionsof memory location 160 and 165, such that address spaces 170 and 190have “read/write” access to locations 160 or 165, respectively.Similarly, page table 180 maps the permissions of memory location 160and 165 for address spaces 175 or 195 as “read/execute,” respectively.Accordingly, when security component 155 (FIG. 1A) receives a request(e.g., 143) from a user mode 113 component, security component 155 cancorrelate the address spaces of the component originating the request(e.g., 143) with the address space for JIT compiler output (e.g., 123).

As previously mentioned, one of the ways that system 100 can enforce thepermission and security layer boundaries is through memory heap 160,which straddles the described security/permission boundaries. Ingeneral, a “memory heap” comprises a set of memory addresses set asideby system 100 during or just prior to runtime. In this particularexample, system 100 can allocate and configure memory heap 160 so thatonly kernel layer components (e.g., JIT compiler 105) can write tomemory heap 160 (e.g., via page table 180), while user layer componentscan only read from memory heap 160. As a result, application program 110cannot execute any compiled code from JIT compiler 105 in memory heap160, but, rather, must do so only in address space 175.

One will appreciate, therefore, that a “sandbox” can be set by requiringoperation of an application only in user mode, and by requiring theapplication and JIT compiler to access certain components or datastructures from a memory address associated with different permissionsets. Accordingly, FIGS. 1A-1B and the corresponding text illustrate anumber of different architectural components that can be used to accessand/or execute virtually any type of executable code, including managedcode, in a secure fashion. In particular, FIGS. 1A-1B and thecorresponding text illustrate how an application can execute in a user113 mode, and access a memory heap with only read or read/executepermissions for the JIT compiled code. In addition, the Figures andcorresponding text illustrate how the application can invoke one or morekernel-layer components in different address space 170, which hasread/write permissions for memory heap 160, and can thus compile andpass managed code to memory heap 160 but not execute it.

As previously mentioned, this type of distributed address spaceconfiguration can provide a number of different benefits to programexecution and development. At the outset, for example, an applicationprogram developer can write virtually any type of code without worryingabout safety considerations (e.g., type-safety) In addition, anoperating system developer need not speed exhaustive resourcesdeveloping the runtime verification code that would force all executingprogram code to be safe (e.g., type-safe).

In addition to the foregoing, implementations of the present inventioncan also be described in terms of flow charts having one or more acts ina method for accomplishing a particular result. In particular, FIGS. 2and 3, and the corresponding text, illustrates flow charts one or moreacts for executing managed code so that safe and unsafe applicationprogram code can be executed without threatening or compromisingsecurity. The methods illustrated in FIGS. 2 and 3 are described belowwith reference to the components and diagrams of FIGS. 1A-1B.

Accordingly, FIG. 2 shows that a method from the perspective clientcomputer system can comprise act 200 of executing an application in afirst address space. Act 200 includes executing an application programin a first address space of a memory location. For example, FIG. 1Bshows that application program 110 is executing from address space 175,which has read/execute permissions for accessing memory location 160(i.e., where the JIT compiled code will be placed and thus designated asread/execute).

FIG. 2 also shows that the method can comprise an act 210 of receiving arequest from the application for intermediate language instructions. Act210 can include receiving one or more requests from the applicationprogram to compile one or more sets of intermediate languageinstructions. For example, the runtime for application program 110 comesacross pointer 140 to intermediate language code 120, which can only beaccessed in kernel 103 mode. As such, the runtime passes the pointer 120as message 143 to security component 155, which processes the request inkernel mode.

In addition, FIG. 2 shows that the method can comprise an act 220 ofcompiling the intermediate language instructions in a second addressspace. Act 220 includes compiling one or more sets of intermediatelanguage instructions into newly compiled code using a JIT compilerrunning in a second address space. For example, upon validating request143, security component 155 prepares and executes one or more requests147 to pass the requested intermediate language code to JIT compiler105. JIT compiler 105 then compiles the intermediate language code 120in the second address space 170, which in this illustration is providedwith read/write permissions to the shared memory heap 160.

Furthermore, FIG. 2 shows that the method can comprise an act 230 ofpassing the compiled code to a shared memory heap. Act 230 includespassing the newly compiled code to a shared memory heap, wherein theapplication program can retrieve the newly compiled code into the firstaddress space. For example, FIGS. 1A and 1B shows that JIT compiler 105,as well as application program 110, have access to memory heap 160. Inparticular, JIT compiler 105 can write to (but not execute in) memoryheap 160, while application program 110 can only read and execute frommemory heap 160. Thus, when JIT compiler 105 compiles and creates code123, the runtime for application program 110 can retrieve compiled code123 into address space 175, and execute the code in user mode.

In addition to the foregoing, FIG. 3 shows that a method in accordancewith an implementation of the present invention of generatingcomputer-executable program code for a computer system in a manner thatuses JIT compilation while avoiding security violations can comprise anact 300 of receiving executable code and code to be compiled. Act 300includes receiving program code that includes executable code and codeto be compiled. For example, operating system 100 receives one or morestorage media, and/or receives a network-based upload of applicationprogram 110. Application program 110 includes executable program code,as well as intermediate language code 115, which is accessed separatelyby one or more kernel layer 103 components.

FIG. 3 also shows that the method can comprise an act 310 of executingthe executable code in a lower-privilege mode. Act 310 includesexecuting the executable code in a lower-privilege mode and in a firstaddress space. For example, FIG. 1A shows that the executable portion ofapplication program 110 is accessed or otherwise executed only in usermode 113, whereas the intermediate language code 115 is only accessed bykernel mode components.

In addition, FIG. 3 shows that the method can comprise an act 310 ofreceiving a pointer for code to be compiled. Act 3TO includes receivingone or more pointers in the executable code for at least some code to becompiled. For example, FIGS. 1A-1B shows application program 110, whichis operating in user mode 113 and in/from address space 175, comprisescompiled code 135, pointer 140 to intermediate language code 120,compiled code 145, and pointer 150 to intermediate language code 125.While executing application program 110 in user mode, the pointers 140and/or 150 will be identified in turn.

Furthermore, FIG. 3 shows that the method can comprise an act 330 ofswitching to a higher-privileged mode. For example, the runtime forapplication program 110 identifies pointer 140 during execution, andidentifies that JIT compiler 105 will need to be initiated. Since JITcompiler 105 will need to operate in kernel mode, system 100 momentarilypauses execution of application 110, switches from user mode to kernelmode, and then initiates JIT compiler 105 as a kernel mode 103component. A message 143, which includes pointer 140, is then passed toa kernel mode 103 security component 155. Security component 155,operating in kernel mode, then evaluates the request to ensure therequest 143 is properly formed, and/or includes the appropriate handles,security identifiers, etc.

Still further, FIG. 3 shows that the method can comprise an act 340 ofcompiling the requested code in a higher-privilege mode. Act 340includes compiling the requested code in a different address space usinga compiler operating in the higher-privilege mode. For example, FIGS. 1Aand 1B show that JIT compiler 105, which is operating in thehigher-privilege kernel layer 103, can compile code 120 in one addressspace (address space 170), and further pass compiled code 123 to memoryheap 160, where the JIT compiler has read/write access. Upon switchingback to user mode, application program 110 can then access the compiledcode 123 and execute this code from an different address space (addressspace 175) which has read/execute permissions for the memory heap 160.

As such, FIGS. 1A-2 and the corresponding text provide a number ofcomponents, modules, and mechanisms that can be used to executeuntrusted code, including managed code, without sacrificing importantsecurity guarantees. As previously described, this can be accomplishedat least in part by separating compilation of intermediate language codeand execution of binary code in separate address spaces for the sameprogram. In addition, this can be accomplished with a type-safe JITcompiler, which compiles intermediate code and passes the compiled codeinto a shared memory heap. The type-safe JIT compiler is configured sothat, while it can accept and compile code that is not type-safe, theJIT compiler, itself, is constrained from operating outside of certainprescribed type-safety boundaries. Still further, this can beaccomplished by ensuring that executable code is only accessed bycomponents operating in user mode, and that intermediate language codeis only accessed by components operating in kernel mode in a read/writeaddress space.

The embodiments of the present invention may comprise a special purposeor general-purpose computer including various computer hardware, asdiscussed in greater detail below. Embodiments within the scope of thepresent invention also include computer-readable media for carrying orhaving computer-executable instructions or data structures storedthereon. Such computer-readable media can be any available media thatcan be accessed by a general purpose or special purpose computer.

By way of example, and not limitation, such computer-readable media cancomprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to carry or store desired program code means inthe form of computer-executable instructions or data structures andwhich can be accessed by a general purpose or special purpose computer.When information is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or a combinationof hardwired or wireless) to a computer, the computer properly views theconnection as a computer-readable medium. Thus, any such connection isproperly termed a computer-readable medium. Combinations of the aboveshould also be included within the scope of computer-readable media.

Computer-executable instructions comprise, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions. Although the subject matter has been described inlanguage specific to structural features and/or methodological acts, itis to be understood that the subject matter defined in the appendedclaims is not necessarily limited to the specific features or actsdescribed above. Rather, the specific features and acts described aboveare disclosed as example forms of implementing the claims.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

1. In a computerized environment comprising a memory, as well as a JITcompiler and one or more application programs loaded in the memory, amethod of executing managed code so that untrusted program code can becompiled and executed in a manner that does not threaten or otherwisecompromise system security, comprising: executing an application programfrom a first address space set with a first set of permissions foraccessing a shared memory heap; receiving one or more requests from theapplication program to compile one or more sets of intermediate languageinstructions; compiling the one or more sets of intermediate languageinstructions into newly compiled code using a JIT compiler running in asecond address space that has a second set of permissions for accessingthe shared memory heap; and passing the newly compiled code to theshared memory heap, wherein the application program can retrieve andexecute the newly compiled code from the first address space.
 2. Themethod as recited in claim 1, further comprising an act of, uponreceiving an indication that the newly compiled code has been passed tothe shared memory heap, switching from a kernel mode to a user modelevel of operation.
 3. The method as recited in claim 2, furthercomprising an act of the application program retrieving the compiledcode, and executing the compiled code from the first address space. 4.The method as recited in claim 1, wherein the first address space isconfigured with read/execute permissions with respect to accessing theshared memory heap, such that no component operating in the firstaddress space can write to the shared memory heap.
 5. The method asrecited in claim 1, wherein the second address space is configured toaccess the memory heap with read/write permissions, such that nocomponent operating in the second address space can execute code in thememory heap.
 6. The method as recited in claim 1, wherein the JITcompiler is operating in a higher-privilege mode, and the applicationprogram is running in a lower-privilege mode.
 7. The method as recitedin claim 1, wherein the JIT compiler is constrained to execute withinone or more type-safety restraints, but configured to accept and compileintermediate language code that is not type-safe.
 8. The method asrecited in claim 7, wherein the JIT compiler performs the acts of:receiving one or more requests to perform a function that violates asecurity restraint for the JIT compiler; and rejecting the one or morerequests to perform the function, or discontinuing compiling the one ormore sets of intermediate language instructions.
 9. The method asrecited in claim 1, further comprising an act of, upon receiving the oneor more requests from the application program, activating a kernel modelevel of operation.
 10. The method as recited in claim 9, wherein theact of activating a kernel mode level of operation includes an act ofinitiating a kernel mode security component.
 11. The method as recitedin claim 10, wherein the one or more requests from the applicationprogram are received by a kernel mode security component.
 12. The methodas recited in claim 11, further comprising an act of the kernel modesecurity component validating the one or more requests from theapplication program.
 13. The method as recited in claim 12, wherein theact of validating the one or more requests comprises an act ofdetermining whether a handle included in the one or more requests isvalid.
 14. In a computerized environment comprising a storage, a JITcompiler, and one or more application programs loaded in memory, amethod of generating computer executable program code in a manner thatuses JIT compilation while avoiding security violations, comprising:receiving application program code that includes executable code andcode to be compiled; executing the executable code in a lower-privilegemode and in a first address space; identifying one or more pointers inthe executable code for at least some code to be compiled; switching toa higher-privilege mode; and compiling the at least some code in adifferent address space using a compiler operating in thehigher-privilege mode.
 15. The method as recited in claim 14, whereinthe application program code comprises part of a video game applicationthat is received from the storage into a video game operating system.16. The method as recited in claim 14, wherein the compiler is atype-safe JIT compiler configured to handle only type-safe requests, butotherwise configured to compile type-safe or non-type-safe intermediatelanguage code.
 17. The method as recited in claim 14, wherein thehigher-privilege mode is a kernel mode level of operation, and thelower-privilege mode is a user level of operation.
 18. The method asrecited in claim 14, wherein the first address space is configured toaccess a memory heap with read/execute permissions, and the secondaddress space is configured to access the memory heap with read/writepermissions.
 19. The method as recited in claim 14, further comprisingthe acts of: switching to the lower-privilege mode upon identifying thatthe at least some code has been compiled; and executing the compiled atleast some code in the first address space.
 20. In a computerizedenvironment comprising a memory, a JIT compiler, and one or moreapplication programs loaded in the memory, a computer program storageproduct having computer executable instructions stored thereon that,when executed, cause one or more processors to perform a methodcomprising: executing an application program from a first address spaceset with a first set of permissions for accessing a shared memory heap;receiving one or more requests from the application program to compileone or more sets of intermediate language instructions; compiling theone or more sets of intermediate language instructions into newlycompiled code using a JIT compiler running in a second address spacethat has a second set of permissions for accessing the shared memoryheap; and passing the newly compiled code to the shared memory heap,wherein the application program can retrieve and execute the newlycompiled code from the first address space.